When a file cannot be recognised, the user will be given a chance to try raw import. A file extension of ".RAW" will automatically select this mode. You should not select this unless you have some idea as to the internal format of the file. No damage to the original file can happen by selecting this mode.
The raw image control dialogue looks like this:
Told you it was complex, but don't despair, it's not as bad as it looks. Let's examine each of the fields and button groups.
The first four fields are pretty straight forward. Width and height define the picture size in pixels and rows. The depth field defines how many bits are used to define each pixel. Offset defines how many bytes to skip from the start of the file to the start of the image data.
Beneath these are three groups of radio buttons and one group of checkboxes.
Palette: This attempts to define a palette to translate the pixel data into colours. However, the decyphering of colour palette information (when available) is extremely complex and so, for this version, it is limited to:
Grey
This is the same as having no colour translation.
IBM-PC EGA mode (Atari ST default 16 colour mode)
Normal EGA for bitmaps stored as IRGB.
Reverse EGA mode
Used when the EGA bitmaps are stored in reverse order (BGRI)
IIgs Standard, IIgs SHR, IIgs 3200
Apple IIgs standard palettes.
Organisation: This is the most complicated part of the raw import. Files can be arranged in many different ways. Some keep each pixel's data in one chunk, others gather all of the most significant bits in one plane, then the next and so on.
Let's look at one pixel of four bits
where "A" is the most significant bit (causes the biggest change in colour or grey leve), and "D" is the least signficant bit (causes the smallest change in colour or grey level). Our hypothetical image can be thought of being made up of width pixels each of four bits as above and height rows of pixels.
Four specific organisations are allowed in this import:
Pixel
Each pixel of the image is complete with all bits following from most to least significant. If the number of bits (depth) is not an exact multiple of 2 (1, 2, 4, 8) then the bits will be packed across bytes.
Plane
The bits which make up the pixels are gathered into planes of similarly significant bits. For example: all the most significant bits are gathered together as if they were a one bit depth image followed by the next to most significant and so on until the least significant bit.
Row
Similar to the plane format, but the bits which make up the first full row of the image are placed one following the other with the next following and so on.
Chunk
This is the most complex format. Based on the row format, it further breaks up the mage into chunks which are interleaved. For eaxample, on the Atari ST, you will see the most significant bits for the first sixteen pixels in the first word, the next most significant bits for the first sixteen bits in the next word and so on down to the least significant bits for the first sixteen pixels in the last word of this group. This then is repeated for the next sixteen pixels and so on for the rest of the image. Imagery takes the size of the chunk from the alignment setting (see below).
Alignment: All data in a file must be aligned such that it takes up an exact multiple of eight bits - one byte. For example: even if each row contains six one-bit pixels, you can't write just six bits, you have to write a byte. This is "byte aligned". However, some systems, such as Microsoft Window's BMP, require alignment to a larger chunk - long (32bits) in the case of BMP. This options lets you select the correct alignment. Byte aligns to the next 8 bits, word to the next 16 and long to the next 32.
Also, if the image's organisation is "chunk", then this setting also determines the size of the chunk.
Options:
Invert
This turns the image into a "negative" of the data. Some computers consider the lowest number (usually zero) to be black and the largest number to be white while other are the other way around.
Swap Bytes
This option reverses the chunks of the image from Motorola to Intel byte order. The chunk size is determined by the alignment setting (see above).
Byte: Not affected.
Word: AB -> BA
Long: ABCD -> DCBA
Flip Horiztonal
This option flips the image from left to right.
Flip Vertical
This option flips the image from top to bottom.
System 7 Support
This version of Imagery has minimal support for System 7 other than to ensure it is compatible, but it does take into account one feature of the System 7 Finder to make using Imagery simpler.
Under System 7, you can drop-launch a program by dragging a file of a type known by that program over the icon for the program. A similar mechanism exists in System 6 and earlier by selecting multiple files including the Imagery program, releasing the shift key and then double-clicking the program icon.
Imagery allows any file type to be dragged over its icon and also allows as many files as you wish to be selected this way. When you drop-launch Imagery, the first copyright screen is skipped, as is the Standard File Selector for selecting files and specifying where you want the file to be saved. Only the TIFF format selection dialog will come up to select the format for all the files in the selection.
A future version will also add AppleEvents to allow other programs and scripting systems to convert a file on the fly with no user interface at all - the Mac equivalent of a Unix filter program.
Special Features
GRASP
In version 1.0 of Imagery, GRASP GL files were unpacked into a collection of PIC and CLP image files and a TEXT control file. In version 0.5, the TEXT file was given a binary file type which made editing it difficult. As well, the text file was not converted from MS-DOS format to Mac format.
In this version, the PIC and CLP image files are now automatically converted to TIFF and the control file is now a TEXT/MACA file which can be opened with TeachText or any other editor which can read standard TEXT files. The MS-DOS format for this text file is now converted to Macintosh format.
What are TIFF Files?
TIFF stands for "Tagged Image File Format" which was developed by Aldus (Pagemaker, Freehand, Superpaint and Digital Darkroom) and Microsoft (Word, Works, Project, File, etc.). It is a machine independent format designed exclusively for bitmap images.
What makes TIFF unique is its tag based system. Other file formats such as the Amiga IFF and Compuserve GIF formats use tags, but neither of these use a directory system to make finding the tags quick and simple, nor do they allow the highly flexible format and extension of the file format that TIFF provides.
TIFF files currently can handle simple monochrome bitmaps, palette based colour images and RGB full colour images of unlimited colour depth (32bits of resolution specification per colour - 4Gig bits of colour info per colour!). As well, there are four compressions schemes: no compression, RLE/Packbits (MacPaint) compression, CCITT-3 Huffman compression (FAX) and LZW (Lempel-Ziv Welch) compression similar to the one used in GIF.
Many PC graphics programs and DTP programs can now support TIFF and several use TIFF as a default format for saving pictures. Similarly, most Mac drawing programs and DTP packages can import and export TIFF format files. If you aren't sure, check under "Import" for your favourite drawing or DTP package to see if it is supported. Several programs on the PC now use TIFF exclusively for their file storage.
While TIFF files cannot support object based images without having them first translated into a bitmap image, they are very effective for storing scanned images (which was the original intent of the file format) as well as complex and high resolution colour drawings. Further, since the format for this file is widely distributed and is open-license, it is easy for anyone who wishes to support this format to add it to existing software. In fact, several companies including Hewlett-Packard and DEST have been distributing low cost developer's kits for TIFF for several years.
TIFF Compliance
The TIFF files Imagery generates comply very strictly to the TIFF 5.0 specs as defined in the Aldus/Microsoft TIFF Standard Specification version 5.0 final dated 8 August 1988, with all defaults selected to allow maximum compatibility with TIFF 4.0. The only exception is that I use the SubfileType tag instead of the recommended NewSubfileType because either will work and the former is still more widely accepted. Similarly, wherever the TIFF 5.0 document mentions that TIFF 4.0 only allowed one of several choices now offered in TIFF 5.0, I have selected that choice to ensure compatibility with older TIFF 4.0 readers.
The writer conforms to TIFF X, R, G, B and P standards as defined in Appendix B of the aforementioned document and includes all required tags for those formats.
None of the generated TIFF files use any form of compression. This is because most Mac and PC programs are still based on TIFF 4.0. TIFF 5.0 adds LZW compression similar to the one used in GIF files, but many readers still cannot support that. When TIFF 5.0 becomes the dominant form, I'll add the compression.
The “TIFF Incompatibility Myth”
One of the most annoying statements to me it the one that goes “Yeah, but the real problem with TIFF is that there are so many incompatible kinds of files...” Well, I’d like to take a moment here to debunk that myth.
One aspect of TIFF files is that there are both standard and non-standard tags. The standard ones are clearly defined in the TIFF specifications, but the specs also allow for developers to create and use their own tags. Tag numbers zero to 32,767 are reserved for standard tags while the “negative” tags (-1 to -32787) are reserved for developers. Further, Microsoft and Aldus are supposed to keep a complete list of assigned tags. What’s supposed to happen is that a developer writes in and requests a block of tags for their own use - they don’t even have to say what the tags are for.
Ok, sounds like a problem, right? How does a reader know what to do with these developer’s tags when there is no way to find out what a tag does?
Well, the answer is this - you don’t have to know. In theory, the image in the file should have all the standard tags and the developer’s tags contain length information. If the tags are correctly formed and written, and if the reader is written correctly, everything should work fine. The image you get may not be perfect, especially if the developer tags contains information about modifying the image, but at least you can get the image out and then reprocess it yourself.
So, why the incompatibility myth?
This comes from two things that stem from two all too common problem - programmer laziness and programmer arrogance. The first happened on the IBM PC. The TIFF specs clearly state that all TIFF readers should be able to read MM (Motorola byte order) and II (Intel byte order) files. Most Macintosh applications which could handle TIFF files in fact did read both forms. However, few PC program would read MM format files. This is laziness and arrogance.
The second problem lay with programmers who simply could not stick to the standard. By this I refer to two things: creating new tags without registering them and worse, not following the specs when writing the standard tags. An excellent example of this is Teletypesetting’s T-Script PostScript rasterising program. Their 1.4 TIFF export module ignored the rule that states that tags must be written in tag number sorted order. Theirs doesn't. Smarter programs (like Aldus’s Freehand program which seems to be able to read correctly just about anything as a TIFF file) will presort the tags anyway just to make sure - others don’t and reject the file.
(The people at Teletypesetting claim that they were working with a newer version of the TIFF standard which allows non-sort order, but I contacted the TIFF support desk at Aldus and they assure me that the 8/8/88 document defining TIFF 5.0 is still the most recent version and that it requires tag sort order. Version 2.0 of TScript fixes this problem.)
Simply put, when the TIFF 5.0 spec is followed to the letter, by programmers writing both readers and writers of TIFF files, there is never a case where any TIFF file will be incompatible with any reader on any CPU, except in cases where the program in question is not capable of working with the data contained within the TIFF file - a monochrome bitmap drawing program would not be able to handle TIFF-G, TIFF-P or TIFF-R files all of which contain colour or grey images.
The only other area of contention is the recent addition of LZW compression. Most readers are still TIFF 4.0 readers which are mostly compatible with TIFF 5.0 files except in two ways - one critical tag has been changed (SubfileType -> NewSubfileType) and LZW compression was added. This is why Imagery generates TIFF 4/5 intermediate files. It does not use LZW and it uses SubfileType tags - which is allowed under TIFF 5.0. Imagery files should be readable by TIFF 4.0 and TIFF 5.0 readers.
I hope this puts an end to the incompatibility myth.
TIFF 6.0
Aldus, who currently seem to be the driving force behind TIFF, are about to release version six of the TIFF specs and there are many new and very interesting features including JPEG support. However, much as LZW compression is still widely unused, almost four years after its introduction to TIFF, I suspect that it may be many years before these features become widely used. This is a great pity because they really have added some impressive new features.
However, until TIFF 6 becomes more widely supported by readers, Imagery will continue to generate TIFF 4/5 compatible files. The upcoming "Pro" version will offer selectable TIFF 4, 5 or 6 mode generation.
User Interface Issues
A couple of Imagery users have written to me about my choice of a user interface. Specifically, they argue that it's not Macintosh-like enough. Two points on that: first, check out Font/DA Mover. Written by Apple, part of the system software package... and it works very much like Imagery.
Second, and more importantly, my idea was to create something which is very commonplace in Unix - a filter. In Unix, it is common to take a file and pass it though a chain of small programs, each of which do one thing, modifying the data and passing it on to the next program in the chain with the final file being written at the end.
This isn't possible on the Mac, but with the addtion of drop-launching, I tried to create a similar idea. You drop the file on the first icon and then pass it through each one until you've filtered the file into a desired form.
The fact is that currently, Imagery isn't graphically oriented. To add menus and windows would make the program less effective, not more so. However, Imagery Pro will include editing and modification windows and will gain a user interface when run directly. It will, however, still include the same drop-launch conversion mode.
No charge may be levied for this program, nor may it be included in any package sold for profit without express authorisation from the author. It may be distributed freely via BBSes and on electronic data services which do not explicitly charge for file downloads, that is, do not charge a per file rate as opposed to a per hour rate, and may be included in freeware/shareware collections as long as no additional charge for its inclusion is levied. Further, no service or distributor may attach additional restrictions to this program or to its distribution. This program must be distributed complete with all documentation and additional programs.
If a book publisher or CDROM manufacturer wishes to include Imagery on their CDROM, I only request that a copy of the book or CDROM be sent to me as a token of the inclusion. Only the first edition of a book or CDROM which includes the program is required. (ie: Only one copy of the book or CDROM is required even if the application is included in later editions.)
The author may be contacted via Compuserve at 76217.2241 or via the Internet at werewolf@netcom.com.
Bugs and Warranties
Warranties: there are none. This is a free program - what do you want for nothing? :-) You use this at your own risk. I've tested it as well as I can and while it's not the best thing I've ever written (although it is getting better) - it is simple, clean and functional.
Bugs: there are probably plenty. I have tried to catch as many as I can, but this was a hack utility which has become sort of a project/hobby and will grow on forever simply because I enjoy playing with it.
Known bugs and weaknesses
In order to make the odd file which aligns a row to a long word rather than to a byte (Windows BMP files for example) fit in with TIFF which is row/byte aligned, I just redefine the image to be a little wider. This results in several pixels of garbage along the m, I'levi vi m must be dise fehouhat ale rate asf a user interface. Specifically, they argue that it's not Macintosh-like enough. Two points on that: first, check out Font/DA Mover. Written by Apple, part of the system software package... and it works very much like Imagery.
Second, and more importantly, my idea was to create something which is very commonplace in Unix - a filter. In Unix, it is common to take a file and pass it though a chain of small programs, each of which do one thing, modifying the data and passing it on to the next program in the chain with the final file being written at the end.
This isn't possible on the Mac, but with the addtion of drop-launching, I tried to create a similar idea. You drop the file on the first icon and then pass it through each one until you've filtered the file into a desired form.
